IBIS Macromodel Task Group Meeting date: 16 May 2017 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai * Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC: * David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - None. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Walter: Motion to approve the minutes. - Radek: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: BIRD 166.3 Redriver Flow: - Arpad: Last week Fangyi's presentation showed that BIRD 166 flow changes could get us into more trouble in some situations, particularly with deconvolution and non-linearities. - We need to make a decision on whether to go forward with BIRD 166 and how to plan to move on with the redriver flows. - Walter: [sharing his "To Dual or not to Dual" presentation] - [slide 2] - Defines the terms Init-Only, GetWave-Only, Dual. - Based on the settings of Init_Returns_Impulse and GetWave_Exists. - Arpad: Does Dual just mean Init_Returns_Impulse and GetWave_Exists are true? - Or, does it mean that GetWave() duplicates all the functionality in Init()? - Walter: When Init_Returns_Impulse is true, the IR output contains all the equalization (limited to LTI portion). - GetWave_Exists being true means the GetWave() function returns a waveform that also includes all the equalization, but GetWave() has the ability to deal with non-LTI behavior. - Arpad: That implies whatever was in the Init() is also in the GetWave()? - Discussion: There was some disagreement over the true definition of a dual model. Arpad's question was getting at whether Init() and GetWave() had to implement their equalization independently. Consider the types of models described by Bob Miller, wherein the Init() function determines the taps based on its input IR. His GetWave() function then applies those same taps, with the possibility of additional corrections for non- linear effects. In such a model, the GetWave() output is not correct if the Init() were not given the proper IR. Walter considered such a model a dual model (because both Init() and GetWave() provide the equalization). Ambrish did not consider such a model a true "dual" model, because the GetWave() output cannot independently achieve the correct equalization (it is reliant upon the Init() flow). Ambrish objected to the GetWave() flow being tied to the IRs available at Init() time. - [slide 3] Additional Configuration Subtleties - GetWave() function's behavior may depend on the IR input to Init(), whether or not Init_Returns_Impulse is True. [Again, models of the type Bob Miller described] - [slide 4] With BIRD 166.3, flow validity. - Note: David suggested replacing "upstream" with "non-terminal". Walter made the change(s) in the document as discussion continued. - Statistical flow valid if: - Init_Returns_Impulse is true for every model. - Time Domain Flow (guaranteed) valid if: - Every non-terminal model has: - Init_Returns_Impulse is true - GetWave_Exists is true - The terminal Rx has: - GetWave_Exists is true - (no requirements for Init_Returns_Impulse) - Ambrish: You are saying the time domain flow is not (guaranteed) valid if Init_Returns_Impulse is false for any of the (non-terminal) models? - David: Yes, based on the models described by Bob Miller. - Ambrish: That's a model requirement (of Bob's models), not a flow requirement. - [slide 5] Problematic Flows - Statistical flow is problematic if any model's Init_Returns_Impulse is false. - Ambrish: Is this a surprise to the model maker? - The model maker understands this if they've chosen to make a GetWave Only model. - [slide 5] continued - Time domain flow is problematic if any non-terminal model has Init_Returns_Impulse set to false. (because it breaks the chain of IRs at Init time and could cause problems for models such as Bob Miller's). - Terminal models are the exception, and only need a GetWave(). - We recognize that the Terminal Rx is a unique model. It may have a CDR, and DFE, and it's adaptive, and people may want to generate GetWave() only models and have difficulty generating a meaningful IR from Init(). - Ambrish: Again, you're saying that if an upstream model has a GetWave(), but it doesn't return an IR from its Init(), that's a problem for a time domain flow? - Walter: Yes. Two years ago I would have said having a GetWave() was enough. - Now we've discovered Bob is delivering models where GetWave() doesn't work properly if the correct IR wasn't given to Init(). - Bob M.: Appropriate for me to give a brief explanation of how we got there. - Historically, the Rx models we were generating were not in channels with repeaters. We were talking to a Tx, particularly ones that were LTI, so it was trivial for them to return an IR from Init(). If everything upstream is LTI, there is no difference between taking that IR and convolving it with an internal bit pattern into a time domain waveform inside Init() or taking the bit-by-bit pattern that comes through the Tx and the channel from the EDA tool in GetWave(). So, in an effort to allow our customers to run Init() based simulation and tune them, we moved our tuning up into Init(). - Ambrish: There's adaptation in GetWave() or no? - Bob M.: For virtually all of the models we've built, there is no adaptation in GetWave(). - Walter: Fangyi noted that some of your models do saturation in GetWave(). - Bob M.: Yes, we encourage our customers to run models in GetWave() because the Rx, in particular, is subject to non-linearities and it's difficult to provide an IR that adequately characterizes the behavior in the presence of non-linearities. - Walter: To summarize, you get the equalization from Init(), but then in GetWave() you can saturate. - Bob M.: Yes, the initialization done in Init() is in the presence of all the Rx non-linearities. So we have a tuning that's valid in GetWave(). - Fangyi: Your GetWave() also has a CDR, doesn't it? - Bob M.: Yes. - Again, I want to say that we were not even considering any repeater problems when we settled on doing models this way. - [slide 6] Problematic Flows continued - Time domain flow is problematic if any model has GetWave_Exists False. - Simulator must create a proxy GetWave() using mathematical operations on the input and output IRs from Init() (such as de-convolution). - This is described in the original AMI flow stuff from 5.1. - Fangyi: That's not true. It's not problematic. - Walter: Problematic - it depends on the actual combination of models. - Fangyi: It's an implementation issue, I wouldn't call it problematic. - [slide 6] continued - Time domain flow can be very problematic with various combinations of Init Only and GetWave Only models. - [slide 7] Ways to fix Init-Only Models - Model makers should never deliver Init Only models. - Init Only models can easily be converted into Dual Models. - One suggestion is to make source code available for this so model makers can do it to their own models. - David Banas has public domain source code for a GetWave() based on the equalization computed during Init(). - Keysight proposal is an alternative - Adds additional IR outputs. - Allows the EDA tool to create proxy GetWave() without deconvolution. - Requires additional functionality in Init() and the EDA tool. - Is it easier than writing a GetWave() to make an Init Only model become Dual? - Michael M: If there were a "statistical" function call, and Init() could go back to being just about setup and configuration, would you still say no to a "statistical"-only Model? - Walter: The EDA tool needs to have a GetWave() or be able to make a proxy GetWave() to apply the equalization to a waveform. - Bob M.: One other difference between the EDA tool handling the GetWave() and the model maker doing it is clock and data recovery. In the Keysight proposal, you already have the source bit pattern, all you need to do is correctly align it so you can apply the DFE based on it to the Rx waveform, without explicit clock and data recovery. We should consider that. - Walter: I agree with having an option to have these additional IR outputs. - I'm just saying we still have to support the legacy models, and I want to present ways to do it. - If a model maker has an Init Only model, he could presently add a GetWave() or in the future add the additional IR outputs. - Bob M: Agreed. - [slide 8] Ways to fix Tx GetWave Only Models - Tx models are almost always LTI and can be well represented by Init(). - Usually no excuse for making a GetWave Only Tx model. - [slide 9] Ways to fix Rx GetWave Only Models - Rx terminal model with CDR, etc. Valid for time domain simulations. - Rx redriver model that is GetWave Only will not be able to influence the IR passed in to downstream Init() functions. - [slide 10] Conclusions - IBIS should clearly recommend Dual models. - Only exception is terminal Rx models - No real excuse for Init Only models - No real excuse for Tx GetWave Only models - One problematic case, Rx redriver models - May contain effects that require GetWave() to be captured properly. - Model maker should still output a best approximation IR from Init so that downstream models' Init() functions see the upstream effects. - Walter: I propose that IBIS only document the following flows: - Statistical flow when all models have Init_Returns_Impulse true. - Time domain flow when all non-terminal models are Dual, and the terminal Rx model may be dual or GetWave Only. - Ambrish: Can we recommend that if it's a GetWave Only model it should still work in a time domain flow? - You're saying it worked that way two years ago. - I understand Bob's model won't work with it. - Shouldn't we say a GetWave Only model always works in a time domain simulation? I'm shocked that we're now suggesting it won't. - Walter: If you add that language to the spec, you effectively deprecate Bob's model. - Ambrish: Doesn't Bob's model effectively violate the flows? - Arpad: It seems we are recommending these two parameters (Init_Returns_Impulse and GetWave_Exists) are always true. - That eliminates a whole bunch of the combinations. - Effectively we are trying to deprecate them, or cause them to be deprecated over time. - Walter: We're not removing them. - We're recommending that they be true. - I'm proposing we document a limited number of flows. - Arpad: Why not just bite the bullet and deprecate them? - Walter: We can say every model should have a GetWave() and deprecate GetWave_Exists. - We can then say every model except the terminal Rx should have Init_Returns_Impulse true. - Michael M: Perhaps we'd be better off to introduce a new function in a new version of IBIS and set up cleaner new flows? - Bob M.: One of the issues is models that adapt in Init() like mine. - What if we introduce a new reserved parameter "Init_Requires_Impulse"? - Then the EDA tool can detect incompatibilities between models. - Ambrish: Why not add adaptation to your GetWave()? - Bob M.: There are problems with adapting in GetWave(), but they are surmountable. - Ambrish: I feel like we are retrofitting the spec for Bob's type of model. - Mike L.: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. ------------- Next meeting: 23 May 2017 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives